[Previous] [Next] [Index]
[Thread]
Re: 40 bit encryption: Missing the point
Chuck> If it means that Netscape (or cern, or W3) makes their
Chuck> server available with 40bit encryption, BUT WITH HOOKS so
Chuck> that I, as the buyer, can EASILY replace it with my
Chuck> licensed RSA algorithms to be used by RSA licensed clients,
Chuck> then I can work with it. Kerberos, PGP, rot13, whatever
Chuck> could be put in by the end user. If it has only the
Chuck> generic hooks and an API, US people could put in PGP
Chuck> (licensed).
As I understand it, the SSL *protocol* already supports a variety of
encryption algorithms (e.g. RC2, RC4, DES, triple DES, IDEA). Once
SSLRef 1.1 accommodates BSAFE, SSLRef/BSAFE-based applications will be
able to negotiate/use many of these for encrypting application data
streams. However, the user/service authentication is still of a
public key nature.
It would be very useful to have a broader choice of security
mechanisms for authentication and encryption (ala Kerberos/DCE, SSL,
etc.), accessible via an *application-independent* API. The GSSAPI
formulated by the IETF CAT WG provides such an API, with current
implementations for Kerberos/DCE and a public key-based mechanism
named SPKM. We are considering implementing SSL as another GSSAPI
mechanism, as well as providing a higher-level API based on the GSSAPI
(e.g. an extended version of the SSLRef API). This would enable a
variety of applications to make use of SSL and other security
mechanisms in a modular fashion, through a uniform/simple API. In
addition, a mechanism negotiation capability is being defined for the
GSS (by the CAT WG), which would enable run-time negotiation of a
common security mechanism among those implemented for the GSSAPI.
- Doug
--
Doug Rosenthal
MCC EINet | Email: rosenthal@mcc.com
3500 W. Balcones Center Dr. | Voice: 512-338-3515
Austin, TX USA 78759 | Fax: 512-338-3897
References: